软件工程师采用新技术的正确方式
大家好，我是飘渺。
前几天跟一个团队技术负责人聊天，他说他们有个小的项目都是直接使用的SpringCloud。
我问他为什么，你这不是为了技术而设计吗？小项目用个单体架构不是很方便吗？
他说我就是想用一下SpringCloud，熟悉一下。
我问他，那你在使用SpringCloud过程中有没有遇到一些问题，比如数据库怎么拆分？事务问题如何解决呢？怎么做的CICD？
他又说我们不拆，就一个库。只不过在应用层规定了服务与服务之间只能通过接口调用，至于分布式事务嘛，暂时还没考虑。
。。。。。。
都说兴趣是最好的老师，热衷新技术本身也是没错的，但是这样很容易造成一个问题就是在做项目的时候为了技术而架构，简单问题复杂化。
那软件工程师到底应该如何应对新技术呢？（当然这里提到的SpringCloud并不算什么新技术了）我们看看 Karl Hughes 是怎么说的！
原文地址：http://t.hk.uy/8yS
2015 年，我带领一支工程团队为大学生构建了一个 Web 应用程序。由于录取工作已于 5 月结束，因此我们只有 3 个月的时间为每年 8 月的流量暴涨做好准备。
第一年我们只有几千个用户，所以没有人担心扩展问题。我们使用了 Angular 前端和 MySQL 数据库，在 PHP 中构建了这款应用。
当我们准备在第二年将用户规模增加到三倍时，我们开始怀疑现有的应用程序能否良好地扩展。我开始学习所有最新的工具，聘请了一位经验丰富的 DevOps 工程师，然后制定了一项负载测试计划。
经过两个半月的混乱，研究了 Docker、Azure Service Mesh 和其他一些最新工具后，我们意识到无法赶上 8 月的截止日期。我们退后一步，重新考虑了所面对的问题。我开始向一些导师寻求建议，记得那天，其中一位叫我出去，对我说：
“你不需要那么多复杂的工具！”他告诉我。“在系统上再扔一台服务器就行了。”
为什么新技术如此吸引人？
像许多工程师一样，我会抓住机会利用所有最酷的新工具。经过几个月的无谓尝试，我终于意识到解决方案本来很简单，并且我们手头已经有了所需的工具。我们水平扩展了 API，垂直扩展了数据库，这花了大约两周时间。
事后看来这显然是正确的选择，但是为什么一开始它就不那么明显呢？为什么甚至颇有经验的软件工程师也会像飞蛾扑火一般被闪亮的新技术所吸引？
新技术承诺解决老问题
管理大量服务器非常困难，一直以来都是一个难题。当我们迁移到云后，这个问题终于变简单了，现在 Kubernetes 承诺可以让这件事情变得更轻松。与所有“烦人的旧东西”相比，新技术有望更快、更高效或更灵活地解决问题。如果你只看那些宣传资料，你可能会认为它们甚至没有任何代价可言。
我们会因为用上了“最新和最棒的技术”而受到关注
我在 2015 年读到的所有文章都在说 Docker 将会有多伟大。他们坚持认为它将在短短几年内取代 VPS。早期采用的公司因此得到了很多正面的报道。我也想要这种关注。
求职者涌向新技术
不幸的是，由 Hacker News 推动的炒作周期使工程师认为他们必须采用最新技术才能跟上时代。对于新手开发人员来说尤其如此。你想不到最近有多少培训班毕业生问我是否在使用新出的 X 或 Y 框架。甚至有人试着劝我将我们的整个关系数据库转移到区块链上。
我们也想变得很酷
“深入其中并对所有事物做现代化改进是很有趣的事情——当然，你可以在此过程中学到很多东西（也许会以牺牲业务为代价）。”——David LeBlanc
我对丰富简历内容没什么兴趣，但我记得那时候我会想：“这将成为一次会议演讲上的精彩故事。”我现在可不敢这么说，因为在 2015 年的早期创业阶段尝试部署 Docker，结果以失败告终的经历，可能是我迄今为止最大的管理败绩。
过早采用新技术的风险
几年前，我发现技术炒作周期是这么一回事：
“炒作周期中，市场先是对某种很棒的新事物有一段时期的夸大宣传，鼓励人们采用——直到技术逐渐真的普及开来，人们才发现新事物并没有广告中所描述的那么神奇。然后这种新事物便会失宠，乃至被完全丢弃或遗忘，直到它的成功所需的知识基础成型为止。”——Dick Dowdell
许多工程师在新技术诞生伊始的高峰期（也就是关注和讨论最多的时期）错误地采用了它们。问题在于，不成熟的技术会有全新和未知的故障机制，而现有的解决方案并不会如此。
软件工程团队需要浪费大量时间寻找不那么明显的错误、查找文档里没有的边缘案例并重写代码来适应新技术。这就是六年前我们尝试采用 Docker 时发生的事情。我们没有足够的资源来遍历所有没有文档支持的特性和选项，而且 API 会随着版本升级而不断变化。
就算这些问题并没有令你困扰，但早期采用者仍会承担技术开发公司倒闭的风险。我记得有几个朋友很早就用上了 RethinkDB，但到了开发它的公司于 2016 年关闭时他们大失所望。尽管它后来作为一个社区维护项目又回来了，但让你的应用程序数据库陷入困境从来都不是什么好事情。
技术采用技巧
既然如此，如果新技术增加了太多不必要的风险，为什么我们都没有停留在 1990 年代的 Java 版本上呢？我们如何才能避免落后太多，以至于连升级途径都找不到呢？当我们开始一个新项目时，我们不应该使用最新的技术工具吗？
针对这些有趣的问题，答案都是“取决于具体情况”。
我已经开始为在软件工程团队中采用新技术的策略制定一些经验法则。请随意使用这些内容，也可以根据你的组织情况做出调整或建立自己的规则集。
给人们时间进行实验
我坚信可以给员工一些时间来在工作中学习新事物。这为他们提供了一种创造力的源泉，使他们保持领先，并能让你尝试一些业务永远不会优先考虑的事情。如果一位工程师使用他的学习时间来证明我们的应用程序中可以使用某些新技术工具，那么我会认真考虑此事。
“在将新技术用于产品之前，需要对新技术进行验证……你必须做出结果。如果不这样做，就是把产品推向了死亡之路。”——Andrew Orsich
保持一个默认技术栈
微服务的罪行之一是，它们鼓励公司使用不同的编程语言来构建应用程序的不同部分。虽然经验丰富的工程师可能会喜欢每周更换语言，但这会增加认知负担，并让新开发人员难以接受。当程序员选择的语言不一样时，团队还会出现一些技术孤岛。选择一个技术栈作为默认选项，仅在真正需要时才做扩展。
保持核心的可靠性
当你选择尝试新技术时，请先考虑将赌注限制在不太重要的功能上。当你基于 SQL 构建平台时，很难采用某种新的、先进的数据库，但是在临时营销站点上尝试新的 UI 库并不难。一旦在非关键任务中验证了这项新技术后，你就可以决定在整个核心应用程序中采用它。
记住业务目标
与我合作过的最优秀的那些工程师始终会牢记“为什么”这一要点。他们在业务价值较低的应用程序部分中节约资源，而会花几周时间来完善核心数据模型。作为经理或团队负责人，你必须随时问自己为什么企业需要这种技术。如果某种新工具进入市场，你就必须判断它会增加多少业务价值以及采用的成本。
结论
新技术并不坏。我喜欢尝试使用新的框架和编程语言，但是作为领导者，你必须在好奇心和业务目标之间取得平衡。人们很容易陷入未经验证的新工具的泡沫中，因此，你应该制定标准来帮助你决定应该何时尝试新的工具。
最后，我是飘渺Jam，一名写代码的架构师，做架构的程序员，期待你的关注。咱们下期见！